In modern operating systems, ordinary unprivileged users are often distinguished from a more-powerful privileged user, sometimes referred to as a super user or “root” in UNIX or UNIX-like operating systems. While a privileged user typically has complete access to all aspects of an operating system (“OS”) and hardware supporting the OS, unprivileged users typically have only limited access to services provided by the OS and have little direct control over the supporting hardware. Thus, an unprivileged user requires additional privileges and rights to perform certain privileged operations, such as installing software packages and updating installed software packages.
Various OS-specific access control mechanisms for granting unprivileged users the permission to perform privileged operations have been devised. For example, systems based on RED HAT LINUX™ distributions usually grant a user access to devices if, and only if, the user is logged in at a local console. In contrast, systems based on DEBIAN LINUX™ distributions often rely on group membership, e.g., users in the “optdrv” group can access optical drives, users in the “rmvdev” group can mount removable media, etc. Furthermore, commands such as “sudo” allow users to perform certain privileged operations with root privileges but without requiring a root password. Finally, software tools such as udev and GNU Network Object Model Environment (“GNOME”) System Tools utilize inter-process communication mechanisms to provide a very narrow and well-defined subset of privileged operations to unprivileged desktop applications.
However, such OS-specific access control mechanisms can impede upstream projects (e.g., GNOME and KDE) from implementing features that require administrative privileges because most downstream consumers (e.g., OSes) implement different and often incompatible access control mechanisms. In addition, existing access control mechanisms are coarsely grained. For example, permission to perform privileged operations may be granted based on whether or not a user is at a console or is a member of a group. To compound the problem, granting permission based solely on group membership can be problematic because in certain OSes, if a user was once a member of a group, that user can become a member of the group again without proper authorization. Furthermore, improper usage of existing access control mechanisms such as sudo can cause full-fledged applications to run as a super user, which can result in millions of lines of code running as root. Not only does such misuse cause those applications to appear out of place because settings in those applications would read per-user settings from root's home directory, it also violates the principle of least privilege and circumvents critical security measures.
Therefore, it may be desirable to provide a mechanism for defining and enforcing a fine-grained access policy for performing privileged operations, such as installing and updating software packages, for instance on a per-package or other basis.